The Test Manager will ensure a code review is performed before the application is released.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-16829	APP5080	SV-53700r1_rule	DCSQ-1	Medium

Description
A code review is a systematic evaluation of computer source code conducted for the purposes of identifying and remediating security flaws. Examples of security flaws include but are not limited to format string exploits, memory leaks, buffer overflows or race conditions. The code review is usually conducted during the application development phase, this allows discovered security issues to be corrected prior to release. A code review can also be performed after the development phase, however, in all instances identified errors must go back to development for correction so conducting the code review during development is the logical and preferred action. Automated code review tools are to be used whenever reviewing application source code. These tools are often incorporated into many Integrated Development Environments (IDE) so code reviews can be conducted during all stages of the development life cycle. Periodically reviewing code during the development phase makes transition to a production environment easier as flaws are continually identified and addressed during the development phase rather than en masse at the end of the development effort. Code review processes and the tools used to conduct the code review analysis will vary depending upon application architecture and the development languages utilized. In addition to automated testing, manual code reviews may also be used to validate or augment automated code review results. Larger projects will have a large code base and will require the use of automated code review tools in order to achieve complete code review coverage. A manual code review may consist of a peer review wherein other programmers on the team manually examine source code and automated code review results for known flaws that introduce security bugs into the application. As with any testing, there is no single best approach and the tests must be tailored to the application architecture. Use of automated tools along with manual review of code and testing results is considered a best practice when conducting code reviews. This method is the most likely way to ensure the maximum number of errors are caught and addressed prior to implementing the application in a production environment. For a list of tools that can be used for source code review, please reference http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html. Please note that reference to these tools does not imply that they have been tested and approved for use by DISA.

Description

A code review is a systematic evaluation of computer source code conducted for the purposes of identifying and remediating security flaws. Examples of security flaws include but are not limited to format string exploits, memory leaks, buffer overflows or race conditions. The code review is usually conducted during the application development phase, this allows discovered security issues to be corrected prior to release. A code review can also be performed after the development phase, however, in all instances identified errors must go back to development for correction so conducting the code review during development is the logical and preferred action. Automated code review tools are to be used whenever reviewing application source code. These tools are often incorporated into many Integrated Development Environments (IDE) so code reviews can be conducted during all stages of the development life cycle. Periodically reviewing code during the development phase makes transition to a production environment easier as flaws are continually identified and addressed during the development phase rather than en masse at the end of the development effort. Code review processes and the tools used to conduct the code review analysis will vary depending upon application architecture and the development languages utilized. In addition to automated testing, manual code reviews may also be used to validate or augment automated code review results. Larger projects will have a large code base and will require the use of automated code review tools in order to achieve complete code review coverage. A manual code review may consist of a peer review wherein other programmers on the team manually examine source code and automated code review results for known flaws that introduce security bugs into the application. As with any testing, there is no single best approach and the tests must be tailored to the application architecture. Use of automated tools along with manual review of code and testing results is considered a best practice when conducting code reviews. This method is the most likely way to ensure the maximum number of errors are caught and addressed prior to implementing the application in a production environment. For a list of tools that can be used for source code review, please reference http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html. Please note that reference to these tools does not imply that they have been tested and approved for use by DISA.

STIG	Date
Application Security and Development Checklist	2014-12-22

Details

Check Text ( C-17828r3_chk )
Ask the application representative to provide evidence of automated code reviews. This will be in the form of a test plan or methodology which identifies application architecture and components as well as a formal report provided by the automated code review tool plus manual testing results. This requirement requires access to the application source code, if the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If an automated application code review is not performed, this is a finding. 2) If analysis of code review results is not performed, this is a finding. 3) If all application code is not being reviewed, this is a finding. 4) If the code review report includes coding errors that have not been fixed, this is a finding. If identified coding errors have been fixed, this is not a finding. 5) If the code reviews indicate the existence of hard-coded IPv4 or IPV6 addresses, it is a finding.

Check Text ( C-17828r3_chk )

Ask the application representative to provide evidence of automated code reviews. This will be in the form of a test plan or methodology which identifies application architecture and components as well as a formal report provided by the automated code review tool plus manual testing results.

This requirement requires access to the application source code, if the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable.

1) If an automated application code review is not performed, this is a finding.

2) If analysis of code review results is not performed, this is a finding.

3) If all application code is not being reviewed, this is a finding.

4) If the code review report includes coding errors that have not been fixed, this is a finding. If identified coding errors have been fixed, this is not a finding.

5) If the code reviews indicate the existence of hard-coded IPv4 or IPV6 addresses, it is a finding.

Fix Text (F-17146r3_fix)
Use automated code review tools, perform manual code reviews to validate and augment automated code review results. Fix identified coding errors and issues prior to releasing application for production use.